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Ihe design review of MTB-103 ("The Protection Audit Mechanisms 
for Multics") raised several issues that requirea further study. 
Most of the concerns expressed dealt with the performance impact 
of protection auditing, particularly in installations not using 
auditing ana/or the access isolation mechanisms. This memo gives 
further details concerning the expected performance cost of 
auditing, ano re-visits several other design issues. 



Potentially auoitable directory control events and faults (those 
wnich require a test to see if auditing is necessary) occur on 
tne order of 5 times a second. Thus, is it important to minimize 
the number, code size, and execution cost of conditional 
sequences and calls for auditing in these areas. The following 
performance-sensitive modules will contain auditing calls in the 
initial implementation. 

oir_control_error - All directory control programs (should) call 
here wnen a process has insufficient access to complete some 
operation. A 3-instruc tion conditional and a 1 4- instruction 
audit call will be inserted just before the return, to audit 
instances of denied access. 

fim - Some slight restructuring and a conditional audit call are 
necessary to audit illegal procedure faults (not including 
legal fc'IS instructions or out-o f -bounds ) and access violation 
faults (not including ring alarms, out-of-bounos , or illegal 
ring order). Audit checking and calling sequence acds about 30 
instructions to fim. 

Current plans for a second-stage implementation will involve 
audit sequences in two additional performance-sensitive modules. 

makeknown - wnen the proposed KST changes (Mlfc-104) are 
implemented, access information in the KST will make it 
possible to audit successful initiations of protected segments 
and directories (those with access class greater than 
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system-low) in makeknown. At the point where a segment or 
Directory is actually aoaed to the KST, about 60 instructions 
of auditing coue will be inserted, Tne auditing of successful 
making known of protected directories, normal protected 
segments, and "system 11 (ring 1 multi-class) segments will be 
governed by separate auoit select flags. For segments with 
system-low access class, a 3- in struct ion test will skip tne 
auditing code. 

find_ - hnen the recursive making Known of parent directories 
fails aue to insufficient authorization to search further, it 
is desirable to log the full pathname of the segment. At 
present, find_ is not structured well enough to do this 
conveniently. A re-write of f i no_ will allow this type of 
auditing, and will probably result in a worthwhile improvement 
in system performance. 

It is expected that, in a system not performing any auditing, the 
execution cost of the additional auditing checks will be around 
20 instructions/second, quite negligible. 



Performance Costs of Auaiting 

An actual auditing call represents somewhere between bOO and I Ouu 
instructions, including the call to protec tion_auoi t_, the calls 
it makes to acquire all the information neeoed for the log, the 
call to syserr, and the later invocation of syserr_locger to copy 
the syserr wired buffer into a paged buffer* Thus, in normal 
system operation (i.e., no user purposely generating extra 
auditable protection events), auditing of all protection events 
for all processes can represent as much as about 5 milliseconds 
overhead per second of real time. This is a significant cost, 
but is not unreasonable if one bears in mind that only 
installations using auditing will pay this cost. 

Given the cost of .5 - I millisecond per audit log entry, it is 
possible for a user to cause a great deal of system overhead by 
repeatedly causing auditable protection events. In installations 
wishing to detect "penetration" attempts, this overhead will 
certainly be justified. Future enhancements of protection 
auditing will probably include detection of significantly 
abnormal auditing frequency, probably with an 
exponentially-weighted per-process auditing frequency meter in 
the pds . 



Message S e g m e ai-Ayjaiiing 

The new message segment design (see MTB-101) marks message 

segments as "multi-class" because they may contain messages of 
many access classes, ana assigns the message segment itself a 
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class equal to the highest class of message it can contain, 
because message segments are manipulated only by ring I 

primitives, and because the actual protected objects are the 
individual messages themselves, initiations of message segments 

are not very interesting security events. The eventual need is 
for some finer-grained auditing of the use of message segments, 
io prevent flooding of the syserr audit log with innocuous 
messages for dprint and absentee request submissions, a separate 

pds audit select flag will control the auditing of ring 1 
multiple class segment initiations. makeKnown will checK for 
tnis case when determining whether to audit the initiation of a 
protected segment. This allows initiations of normal protected 
segments to be audited without requiring "system segment" 
initiations to be audited. 



A udit Selectivity Classes 

Mainly for performance reasons, the auoit selectivity classes 
defined in Mfb-103 have been redefined. There are two groups of 
flags (in the left and right 16 bits of a word in tne pds), one 
group for events audited directly in ring 0, and one group for 
events audited via a gate from ring 1. 

ring LL-autiit selectivity classes* 

- initiations of protected non-oirectory segments (tnose with 
access class greater than system-low), not including ring 1 
multi-class segments 

- ma King known of protected directories (These are separated 
out because many directories may be maoe Known as 
by-prooucts of other operations. Knowledge of the maKing 
Known of a protected directory is generally of less 
importance than the initiation of a protected non-directory 
segment. ) 

- initiations of ring I multi-class segments 

- access denied to any segment or directory oue to improper 
authorization, ACL mode, or ring validation level 

- ring-related access violation faults (except ring alarms ano 
illegal ring orders) 

- ACL mode related access violation faults (except 
out-of-bounos ) 

- illegal procedure faults (except legal HIS faults and 
out-of-bounds) 
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- attempted IPC seno-downs 

- assignment of system privileges to a process (eitner blanket 
privileges, or privileged initiation of single segments) 

- rejectee device attachments (tape ano disk drives) 

- protection related actions of the SSA (performed by ring 0 
primitives) sucn as segment downgrading and turning off 
securi ty-out-of-serv ice 



Per-Segment Audit Selectivity 

being able to audit the use and attempted misuse of specific 
segments for all processes allows the use of selected protected 
information to be monitored without requiring the auditing of all 
use and attempted misuse of all protected information for all 
processes . 

ine initial design of this capability used a bit in the brancn to 
cause auditing on all initiations, access denials, and access 
violation and illegal procedure faults. The cost of cnecKinc a 
bit in the brancn during fault processing is far too high for the 
marginal value of auditing such faults, so no per-segment 
auditing will be done on faults. 

As per-segment audit flags will change infrequently, and since 
such cnanges will not need to become effective immediately, this 
flag can. oe copied into the KSi entry when the segment is made 
known, to save directory locking. 

As per-segment audit selectivity is not an immediate necessity, 
the only change will be to reserve a bit in tne branch and a bit 
in the KST. 



To provide concrete oata on questions of protection auditing 
performance, some meters will be addeo: 

f ault s - No one seems to have any good idea of the frequencies of 
various kinos of faults. A simple aos instruction in fim will 
provide a histogram of faults that reacn fim. The histogram will 
go into the unuseo space in wi reo__harocore__oata . Inese meters 




rejected media (tape and disk) mounts 



message segment protection events (such as overflows) 
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may not be permanent. 

a uditing checKs - Some temporary meters will be useful to 
determine how often audit checks are made. At each place where 
an audit select flag is checked in ring 0, a counter in 
active_nardcore_aata will be updated. Since tnese meters will 
definitely reference an additional page each time an aucit flag 
is checked, tney will not be permanent. 

a uditing time and paging - Some permanent meters maintained by 
protection__audi t_ will record in active__haracore_data the average 
time and page faults spent logging audit messages. 



